1. Technical Field
This invention generally relates to object-oriented programming. More specifically, this invention relates to reducing the complexity of object interfaces.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Modern computer systems vary in their design and architecture, with many different models available to achieve the desired combination of speed, power and efficiency for any given computing environment.
Computer systems typically include operating system software that controls the basic functions of the computer, and one or more software applications that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the software applications designed for high performance computer systems have become extremely powerful.
Object-oriented programming, based on an object model, is a new way of creating computer programs that has become very popular over the past several years. The goal of using object-oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. By creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Objects help program designers to make better products faster because objects are reusable, have defined interfaces, and are already tested. In addition, some of an object""s interface (where other objects are allowed access to some of the internals of the particular object) and much of the internal workings of the object can be changed without changing the objects that use the particular object. In other words, if Object A uses Object B to perform a certain function, the way that Object B actually performs that function can be changed without any changes to Object A or without changes to Object B""s interface. Because the inner workings of objects are xe2x80x9chidden,xe2x80x9d objects can be changed to a great degree without causing changes to outside objects. Another benefit of having the inner workings hidden is that the program designer does not need an understanding of how the object works; instead, the program designer only needs to know what the object does. In this way, the program designer can merely use the object without spending an inordinate amount of time either programming another function to perform the object""s function or examining the object to see how it works.
Because of the tremendous improvement in programming simplicity and reuse provided by objects, object-oriented programming has become extremely popular. Many software companies have attempted to make objects even easier to use. For instance, to help program designers who are designing object-oriented programs, computer software manufacturers have designed certain tools to make object-oriented programming easier. One such tool is a visual compiler that shows program designers how the various objects are connected and what their interfaces are. Using these tools, program designers can simply xe2x80x9cdrag and dropxe2x80x9d pre-made objects from a xe2x80x9cpalettexe2x80x9d and onto a xe2x80x9ccanvasxe2x80x9d and then connect the objects together. The visual nature of these development tools makes it relatively easy, at least for small programs, to see how the program is designed.
In addition to visual tools, software companies have begun to xe2x80x9cpackagexe2x80x9d objects. This packaging of objects can take several forms. One such form, allowed by most visual compilers, is the idea of components. Components are pre-built objects that perform various functions. The computer scientist who actually programs the component is called the xe2x80x9ccomponent creator,xe2x80x9d xe2x80x9ccomponent builder,xe2x80x9d or xe2x80x9cdeveloper.xe2x80x9d Both the computer scientist who programs the component and the programmer who uses the component are actually xe2x80x9cdevelopersxe2x80x9d; however, to clearly demarcate who is actually creating the component, only the component builder will be called a xe2x80x9cdeveloper.xe2x80x9d The programmer actually using the component is called the xe2x80x9cassemblerxe2x80x9d or xe2x80x9cprogram designer.xe2x80x9d Assemblers or program designers choose the pre-designed component that meets their needs, and drop or add the component from the palette to the canvas. Assemblers can also modify the component, if necessary, to perform the assembler""s desired function. In addition, assemblers can make their own components that they can then reuse at a later time. Assemblers can combine their own components or other pre-made components into a program by placing each component onto the canvas and connecting all components together.
The second form object packaging includes the use of pre-made components obtained from a software vendor. In this case, the software vendor, as the component builder, creates generic components that are applicable to many tasks and then licenses these components to software program designers. Both parties benefit from this arrangement because the assemblers get a well-defined, thoroughly tested infrastructure upon which to base their applications, and the software vendors receive an influx of money from licensing fees.
Even though visual development systems and components are tremendously useful development tools in simple environments, they suffer from connectivity problems when employed in more complex situations. When an assembler adds an object or component onto the assembler""s canvas, the assembler must then connect this new object to the old objects that will be interfacing with (or to) the new object. Connections are made to provide paths for data flow between components. The paths for data flow are generally method calls, wherein one component is calling another component""s method and sending and/or receiving data at the same time. The connection symbol between objects is visually represented by a line. The connectivity problem in complex environments occurs for at least two reasons.
First, the number of lines on the canvas quickly becomes so large as to partially or completely obscure the objects and components. Second, the complexity of even small designs becomes quickly overwhelming with each added component. This occurs because each component may have many connections to multiple components. Even with a relatively small number of components on a canvas, the number of interconnections between the components will be so large that the structure of the program becomes lost in the extreme number of interconnections. The program designer can no longer ascertain what the structure of the program is. The benefit of having a visual design tool that quickly shows the structure of the project is lost in the morass of connection symbols.
For instance, if the assembler is designing a program that will keep track of a company""s car lots, the assembler might have a canvas having a company component, two car lot components, and import and domestic components for each car lot component. In this relatively simple program, the company component is connected to the two car lot components and each car lot component is connected to its own import and domestic component (which indicate import and domestic cars, respectively). Now assume a more realistic example, where the company owns several different car lots under various names in different states. Each car lot may or may not be affiliated with its neighboring car lot in the same state. Each car lot sells many, few, or only one brand of car. Furthermore, each of the import and domestic vehicles are divided into brands, major types of cars (e.g.xe2x80x94sport-utility vehicles, compacts, minivans), models, etc. Each model also has many options (e.g.xe2x80x94sun roof, color, fancy wheels). The assembler must interconnect all of these various properties, versions of cars, car lots, and affiliates, while also ascertaining the number of different components needed and what the interfaces for each component are. In short, the assembler must spend a large quantity of time programming and interconnecting many different components that perform different roles. In addition, each component or object adds more real and visual complexity to the assembler""s program. The tasks of tracking the role of each object, connecting the objects, and tracking the overall functionality of the programming to verify that each object is correctly fulfilling the desired activities of the desired roles, can become overwhelming.
While adding functionality in the form of roles to components, is a very desirable goal, the implementations available today are overly complex and resource intensive. Without a method for reducing the complexity associated with adapting the role of components in an object-oriented programming environment, assemblers will, as a matter of course, continue to experience unnecessary limitations when programming components to operate with and accept multiple roles.
The preferred embodiments of the present invention provide a method and apparatus for changing a component""s functionality or xe2x80x9cmodexe2x80x9d such that a given component is able to interoperate with a wide variety of other components and to fulfill many different roles. In addition, the preferred embodiments can cause a first component to change its functionality based on the component to which the first component is connected. This change of functionality occurs without any required input from an assembler. By creating a single component which can adopt many different roles, the overall complexity associated with program development and component assembly can be greatly reduced.
A component role fulfillment mechanism, as part of a first component, causes the first component to select or adopt one of its many prospective roles such that it will properly operate with a second component to which it has been connected. The component role fulfillment mechanism recognizes the environment in which the component is placed and selects one of the possible roles available to a given component based on the environment into which the component is introduced. The component environment is determined by the method connections made to the first component from the second component. Thus, the method connection or connections between the first and second component determine both the environment and the role the first component is in. Because one component can take on a variety of different roles depending on to which component the one component is connected, component redundancy is greatly reduced and programs can be assembled more quickly. In addition, because each component can perform a multiplicity of different functions at the same time (i.e. xe2x80x94the component can be both a car and a car lot), design complexity is reduced.